1 A Specification Language for Distributed Components implemented in GCM / ProActive

1.1 Introduction 1.1.1 Goals and scope of the component model This chapter is based on a component model for distributed components called GCM for Grid Component Model. We present here this component model, its reference implementation based on the Java middleware ProActive, our specification language, JDC, adapted to distributed software components, and the associated specification platform: Vercors. From the specification of components and their behaviour, our aim is to both verify properties of this behaviour and generate code for real GCM components. The OASIS team works in the area of distributed systems, with a stress on programming methodology and tools for computational grids. We base our programming model on active objects: each active object has its own (and unique) thread, processing asynchronous method calls on the object. Analysing the behaviour of distributed systems always has been more difficult than for traditional systems, because of the complexity of temporal interactions between remote parts of the application. However, the programming model proposed by our team (featured by the ProActive library [1] implementing the ASP calculus[2]) intends to ease the analysis of concurrency by clearly identifying entry points for communications and limiting the concurrency aspects to several remote method calls on the same object. Moreover, structuring distributed systems using components is somewhat better, because it requires interaction points (service points, but also required interfaces) to be well defined. Additionally , these well-defined boundaries reduce the amount of information that one component needs to have about its environment. Unfortunately, developers still have to face non-trivial runtime incompatibilities when assembling off-the-shelf components. These arise due to the lack of a precise dynamic specification of the component behaviour (the protocols for inter-component communication). In fact, state-of-the-art implementations of component models such as Fractal [3] and the CORBA Component Model [4] only consider type-compatibility for binding interfaces. Nonetheless, a much more precise, sound static compatibility check of bound interfaces can be achieved if behavioural information is added to the components. In such effort, we proposed in [5] to attach behaviour as part of the architecture specification, defined in terms of parameterized networks of transition systems. The compatibility between these behaviours can be checked using model-checkers as we did in [6]. In the same spirit, " behavior protocols " [7] and " component-interaction automata " [8] are ongoing research projects with similar goals. They both adopt a simpler model than ours, for example the " behavior protocols " …